In a host-based mobility protocol, e.g., DSMIPv6, a user equipment (UE) (or mobile node) typically extends its Internet Protocol (IP) stack and implements IP mobility signaling as the UE moves and changes its point of attachment. For this reason, DSMIPv6 is often referred as a client MIP (CMIP).
FIG. 1 illustrates a conventional network 100 including a user equipment (UE) 106, an access router (AR) 108, and a home agent (HA) 110. As shown in FIG. 1, user equipment 106 is connected to a home network 104 via a visited network 102. FIG. 2 illustrates a conventional attach procedure 200 during which a user equipment 106 gains network connectivity to a home network 104 via a foreign link (visited network 102).
Referring to FIG. 2, at step 202, user equipment 106 performs a layer 2 specific attach procedure with access router 108. At step 204, user equipment 106 performs a layer 3 specific procedure to configure an IP address on an interface of user equipment 106. By performing a home link detection procedure, user equipment 106 detects that user equipment 106 is not at home and therefore, the IP address previously obtained is a care-of address (CoA). At step 206, user equipment 106 then initiates a bootstrapping procedure to obtain an IP address of home agent 110, if not available, using either DHCP or DNS. At step 208, user equipment 106 runs an IKEv2 protocol with home agent 110 to establish an IPSec security association. User equipment 106 can also obtain a home address (HoA) and a home network prefix during this procedure.
At step 210, user equipment 106 registers the binding between the care-of address and the home address in a Binding Update message with home agent 110. Upon receiving this Binding Update message, home agent 110 creates a binding between the care-of address and the home address in a Binding Cache entry. At step 212, a Binding Acknowledgement message, if requested, is sent back from home agent 110 to notify user equipment 106 of the status of the Binding Update procedure. At step 214, user equipment 106 gains network connectivity and can send or receive data traffic from a correspondent node (CN) 112 at the current point of attachment.
As shown in FIG. 2, the Mobile IPv6 binding update procedure contains only at most two steps: (i) sending the binding update message from the UE to the PGW (home agent), and (ii) receiving the binding acknowledgement message sent from the PGW (home agent) to the UE, if requested. The security model of this mechanism is that the PGW authenticates the UE during the IPsec security association setup procedure based on the UE identity (such as the IMSI in the 3GPP standard) and the associated security credential. However, in reality, a malicious attacker can obtain a prepaid cell phone, for example, from any store without presenting a real user identity. Therefore, should the attacker launch an attack and such attack is detected, a law enforcement agency will not be able track down the real identity of the attacker.
Creation of Routing Loops in a Network
A routing loop can be created in the network by a malicious UE which while being connected to multiple PDN GWs tries to modify the binding cache in such a way that the PDN GWs forward the packets to one other forming a routing loop. In the example shown in FIG. 3, a UE 302 connects to a trusted/untrusted access network 304 and receives a local care-of address (CoA) and initiates a DSMIPv6 bootstrapping procedure. The UE then connects to one PDN GW (PGW #1) and receives a Home address (HoA1) for that PDN GW. The UE 302 may then send a binding update message to create binding cache between HOA1→COA1 in the PDN GW#1. The UE can subsequently perform a bootstrapping procedure with a second PDN GW (PGW #2) using the IP address from PDN GW#1—i.e., using HoA1 for bootstrapping procedures as the care-of address—and receive HoA2 from PDN GW#2. The UE 302 may send binding update message to PDN GW#2 to create a binding cache entry as HoA2→HoA1, thus creating an erroneous entry. The UE 302 may then send a Binding update message again to PGW #1 to update the binding cache entry in such a way that HoA1→HoA2, thus creating a routing loop 306 between PDN GWs. Packets forwarded to any of the Home addresses (HoA1 or HoA2) would continue circulating between the PDN GWs.
As a second example, when the UE 302 connects to access network 304 and obtains a valid care-of address, the UE 302 performs the bootstrapping procedure and sets up connectivity to PGW #1 and PGW #2 by obtaining the home addresses, HoA1 and HoA2 from PGW #1 and PGW #2, respectively. The UE 302 then performs the binding update procedure with PGW #1 and PGW #2, respectively. Later, the UE 302 tries to update the Binding Cache entry at PGW #1 and PGW #2 to create a routing loop. For example, the packet sent to PGW #1 could be as follows: CoA→PGW #1∥HoA1→PGW #2∥HoA2→PGW #2∥BU. Note that the inner IP headers and payloads in this packet could be encrypted. When PGW #1 receives and verifies such packet, PGW #1 forwards the inner packet HoA1→PGW #2∥HoA2→PGW #2∥BU to PGW #2. Such packet when received will be considered as a valid binding update message by PGW #2; therefore, the binding cache entry at PGW #2 is updated to use the HoA1 as a care-of address. Similarly, the packet sent to PGW #2 could be as follows: CoA→PGW #2∥HoA2→PGW #1∥HoA1→PGW #1∥BU. Note that the inner IP headers and payloads in this packet could be also encrypted. And after processing, the binding cache entry at PGW #1 is updated to use the HoA2 as a care-of address. Now the routing loop is formed.
In addition to sending malicious packets simultaneously to PGW #1 and PGW #2 as described above, the malicious UE 302 may send such attack packets sequentially. For example, the UE 302 may firstly update the binding cache entry at PGW #2 by sending the following packet: CoA→PGW #1∥HoA1→PGW #2∥HoA2→PGW #2∥BU. Note that the inner IP headers and payloads in this packet could be encrypted. After processing, the binding cache entry at PGW #2 uses the HoA1 as a care-of address. Now, the UE 302 sends the following packet: CoA→PGW #1∥HoA1→PGW #2∥HoA2→PGW #1∥HoA1→PGW #1∥BU. Note that the inner IP headers and payloads in this packet could also be encrypted. This packet is received by PGW #1 and forwarded to PGW #2 and finally forwarded to PGW #1; PGW #1 processes the packet as a binding update message and modifies the binding cache entry to use the HoA2 as a care-of address. Now the routing loop is formed between PGW #1 and PGW #2.
In a third example, the UE 302 may send malicious packets to PGW #1 and PGW #2, respectively. The packet sent to PGW #1 can appear as follows: CoA→PGW #1∥HoA2→PGW #1∥home address destination option (HoA1)∥BU and the packet sent to PGW #2 can appear as follows: CoA→PGW #2∥HoA1→PGW #2∥home address destination option (HoA2)∥BU. Note that the inner IP headers and payloads could be encrypted. After PGW #1 and PGW #2 process the received packets, the routing loop is formed.
Note that even though ingress filtering can be deployed at the ePDG or the trusted non3GPP access network to prevent a UE from sending messages with an invalid care-of address, this does not completely solve the problem as UE can piggyback a binding update message in the IPv6 payload and use the valid care-of address to send it to one PDN GW and have final destination as another PDN GW. This attack case is also illustrated by the scenario described above. Furthermore, besides the Mobile IP tunnel, other tunnels, such as an IPsec tunnel established between network entities, can be used for packet forwarding; therefore, an attacker may use the IPsec tunnel together with the Mobile IP tunnel during attacks for further evading security check and detection.
There are conventional solutions which would enable a PDN GW to add an identifier (or value) in data packets, which identifier would help the PDN GW to detect a routing loop and hence drop such packets and delete the corresponding binding cache entries. However such solutions do not prevent routing loops from being created in the first place, thus lots of network resources are generally consumed before such routing loops are detected and terminated. Furthermore, the solution of using a static identifier, such as the IP address of the PGW, has the following drawbacks: 1) since such identifier may be well known, a malicious attacker may eavesdrop a valid packet sent to a specific PGW, and then replay such packet with the identifier of such PGW added to such PGW, which may trigger the PGW to delete the binding cache entry of an innocent UE because the PGW thought the packet is forwarded through a routing loop; 2) using such identifier may leak information of operator's network, and such information is usually private and sensitive. It is challenging for a PGW to keep tracking a large number of random numbers added to each packet, given that a PGW may serve hundreds of thousands of UEs simultaneously. This not only requires a lot of memory consumption, but also introduces processing delay caused by searching and comparing the stored random numbers.
There is another proposed solution that tests the reachability of the care-of address received in the binding update message by sending an ICMP echo message to such care-of address. However, such solution still allows the routing loop to be formed and such routing loop may stay until the PGW removes (or terminates) the routing loop due to failure to receive an ICMP reply message within a certain time of period. The UE may repeatedly launch the attack to form the routing loop in the PGWs to maximize the effect of the attack.
Preventing a UE from Connecting Through DSMIPv6
Consider a scenario, as shown in FIG. 4, where a UE supporting DSMIPv6 connects to a network 400 that selects PMIPv6 for providing connectivity to the UE. The network 400 may however also support DSMIPv6. The UE when connecting to such network would be provided with a Home address say HoA1, by performing PMIPv6 procedures to the PDN GW. The UE receives this IP address and if no IP mobility mode selection is performed and UE does not know about the selected protocol, then the UE would treat this IP address as the Care-of Address to use in the DSMIPv6 procedure. The UE would first discover the PDN GW which may or may not be the same PDN GW. Then the UE will initiate the bootstrapping procedure and create a binding cache entry. If a different PDN GW is selected then packets are forwarded from PDN GW#2 to PDN GW#1 thus creating unnecessary overhead on the network. Moreover the network does not want UE to use DSMIPv6 at all and hence decided to use PMIPv6. Currently, there is no mechanism for the network to stop such a UE from creating a DSMIPv6 tunnel over the already existing PMIPv6 tunnel.